When writing computer programs, a programmer writes a source code file in a high level human readable language. "C" and "C++" are two of these languages that are often used. In these languages the programmer typically writes code to perform a particular application or function. This source code file is then provided to a compiler which takes the source code as input and generates a binary non-human readable object deck. Many of these binary object decks are combined to complete a machine executable program. To build this complete executable program or load module, a linker binds together separate object decks into a single functional program. Each object deck defines and references symbols by name. The linker also resolves the corresponding definitions and references to the definitions which may be in different object decks.
The compiler generates object decks which reference symbols which are in a modifiable data area and in a format which is not supported by the system linker/loader. These references to symbols may be linked later with a definition or may be left partially linked. If only partially linked, the linking would be resolved at runtime.
With current compilers it is necessary to resolve the symbol definitions when the object decks are being linked by the linker. See, for example, the compilers used on the S/370 Data Processing System (DPS) available from International Business Machines Corporation. With this system copies of the object decks must be statically linked in to each application that uses them.
Having to statically link each object deck to each application that uses it creates a number of problems. For example, the size of the object code file becomes very large since it is necessary to have many copies of object decks. Each of the various programs that needs one of the definitions at link-time must have a copy of the object deck available to it and the only way it can do that, where it must be statically linked to the application, is by making a copy of the object deck. Obviously, it would be preferable to have a single copy of each object deck which is made available to each application without the need for each application to retain its own copy.
It is also very difficult to maintain the code in the decks when there are multiple copies to locate and fix. A fix to a single piece of code would require statically relinking all the programs that use that code. If the compilation unit were maintained in only one place then making a fix would be relatively easy.
A Dynamic link library (DLL) is a collection of one or more functions or variables which are gathered into a load module. The so-gathered load module contains executable code accessible from a separate application load module or another DLL. The connection (link) from the application to the functions or varibles in the DLL is not made statically at application build-time but dynamically during execution of the application.
Dynamic link libraries (DLLs) are used to delay the linking of referenced symbols until application runtime. The term symbol is used herein to define either or both of functions and variables held in a DLL. This enables all applications to use the same DLL's. This solves the problem of storing and maintaining multiple copies of each object deck containing definitions of referenced symbols. The use of DLL's also allows a function call or a variable reference in one load module to access a definition in another load module.
The implementation of most DLLs requires address modification of symbols in the load module at runtime. This makes the program non-reentrant so that all users cannot share the same code area of a DLL. An embodiment of the invention provides a method of ensuring that the modification to the DLL does not require a modification in the load module. This makes the program, reentrant.
U.S. Pat. no. 5,175,828 to Michael L. Hall describes a dynamic linker which preserves the program's data and state but changing instructions in the programs functions (code area).
U.S. Pat. no. 5,247,678 to James G. Littleton describes a dynamic linker which does the address fix ups in the code-area. As a result, the applications are non-reentrant.
U.S. Pat. no. 5,297,291 to Daniel L. Murphy describes an ordered list of exported symbols which remains in that fixed order provided by the programmer to construct a symbol vector and that the linker and operating system use this vector.
U.S. Pat. no. 5,339,430 to Kennith Lundin describes the dynamic linking required to install new versions of software modules (libraries) while they are in use by an application.